<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="zh" xml:lang="zh" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Task Descriptor: Implement Test</title>
<meta name="uma.type" content="TaskDescriptor">
<meta name="uma.name" content="implement_test">
<meta name="uma.presentationName" content="Implement Test">
<meta name="uma.guid" content="_yfaCEEoiEdqrjq4i3fchvA">
<meta name="element_type" content="TaskDescriptor">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../css/default.css" type="text/css">
<script src="./../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ActivityTreeTable.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ProcessElementPage.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/processElementData.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var defaultQueryStr = '?proc={35359DDF-6361-43E5-8B1B-18D204DA8CFF}&path={35359DDF-6361-43E5-8B1B-18D204DA8CFF},{CD77CBDA-CC13-4593-BB81-41AF3FF7A84C},_yfaCEEoiEdqrjq4i3fchvA';
					var backPath = './../../';
					var imgPath = './../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, true, true, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top">
<div id="page-guid" value="_yfaCEEoiEdqrjq4i3fchvA"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Task Descriptor: Implement Test</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../images/taskdes_lg_dgm32.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">This task describes how to develop standalone or collaborating tests.</td>
</tr>
<tr>
<td>Based on Method Task: <a href="./../../rup/tasks/implement_test_35C1B0AA.html" guid="{BC805E79-736B-42D5-BDC1-B95E7D002312}">Implement Test</a></td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Roles</th><td class="sectionTableCell" width="30%"><span class="sectionTableCellHeading">Main:
								</span>
<ul>
<li>
<a href="./../../rup/capabilitypatterns/rup_tester_C6E9AC4C.html" guid="_CUdnwRi2Edq_uI8xTPML6g">测试员</a>
</li>
</ul>
</td><td class="sectionTableCell" width="30%"><span class="sectionTableCellHeading">Additional:
								</span></td><td class="sectionTableCell"><span class="sectionTableCellHeading">Assisting:
								</span></td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Inputs</th><td class="sectionTableCell" width="30%"><span class="sectionTableCellHeading">Mandatory:
								</span>
<ul>
<li>
<a href="./../../rup/capabilitypatterns/rup_test_strategy_C055A7E6.html" guid="_CUXhIxi2Edq_uI8xTPML6g">测试策略</a>
</li>
<li>
<a href="./../../rup/capabilitypatterns/rup_test_ideas_list_B582C062.html" guid="_CUdnwhi2Edq_uI8xTPML6g">测试构想列表</a>
</li>
<li>
<a href="./../../rup/capabilitypatterns/rup_test_data_7A49A9F5.html" guid="_CUXhJhi2Edq_uI8xTPML6g">测试数据</a>
</li>
</ul>
</td><td class="sectionTableCell" width="30%"><span class="sectionTableCellHeading">Optional:
								</span>
<ul>
<li>
<a href="./../../rup/capabilitypatterns/rup_test_environment_configuration_3EDB8C14.html" guid="_CUXhKhi2Edq_uI8xTPML6g">测试环境配置</a>
</li>
<li>
<a href="./../../rup/capabilitypatterns/rup_test_script_B5B7C7D6.html" guid="_CUXhIhi2Edq_uI8xTPML6g">测试脚本</a>
</li>
<li>
<a href="./../../rup/capabilitypatterns/rup_test_case_45A497EE.html" guid="_CUXhKBi2Edq_uI8xTPML6g">测试用例</a>
</li>
<li>
<a href="./../../rup/capabilitypatterns/rup_test_automation_architecture_84E78A05.html" guid="_CUXhJxi2Edq_uI8xTPML6g">测试自动化架构</a>
</li>
<li>
<a href="./../../rup/capabilitypatterns/rup_build_37C4FEE9.html" guid="_yfyckEoiEdqrjq4i3fchvA">工作版本</a>
</li>
<li>
<a href="./../../rup/capabilitypatterns/rup_workload_analysis_model_C020A072.html" guid="_CUdnwxi2Edq_uI8xTPML6g">工作负载分析模型</a>
</li>
<li>
<a href="./../../rup/capabilitypatterns/rup_development_infrastructure_F890B593.html" guid="_urrRwUoiEdqrjq4i3fchvA">开发基础结构</a>
</li>
<li>
<a href="./../../rup/capabilitypatterns/rup_test_class_7A14A281.html" guid="_CUdnxhi2Edq_uI8xTPML6g">可测性类</a>
</li>
<li>
<a href="./../../rup/capabilitypatterns/rup_project_specific_guidelines_8112B5CF.html" guid="_CUXhJBi2Edq_uI8xTPML6g">特定于项目的指南</a>
</li>
</ul>
</td><td class="sectionTableCell"><span class="sectionTableCellHeading">External:
								</span>
<ul>
<li>None</li>
</ul>
</td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Outputs</th><td class="sectionTableCell" colspan="3">
<ul>
<li>
<a href="./../../rup/capabilitypatterns/rup_test_script_B5B7C7D6.html" guid="_CUXhIhi2Edq_uI8xTPML6g">测试脚本</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Steps</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="sectionTableCell">
<div class="stepHeading"> Select appropriate implementation technique </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="SelectImplementTechnique" name="SelectImplementTechnique"></a> 
<div align="left">
    <table     style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"      cellspacing="0" bordercolordark="#808080" cellpadding="4" width="100%" bordercolorlight="#808080" border="1">
        <tbody>
            <tr>
                <td width="5%">
                    <b>Purpose:</b>&nbsp;
                </td>
                <td width="95%">
                    To determine the appropriate technique to implement the test.&nbsp;
                </td>
            </tr>
        </tbody>
    </table><br />
</div>
<p>
    Select the most appropriate technique to implement the test. For each test that you want to conduct, consider
    implementing at least one Test Script. In some instances, the implementation for a given test will span multiple Test
    Scripts. In others, a single Test Script will provide the implementation for multiple tests.
</p>
<p>
    Typical methods for implementing tests include writing a textual description in the form of a script to be followed
    (for manual testing) and the programming, captured-recording or generation of a script-based programming language (for
    automated testing). Each method is discussed in the following sections.
</p>
<p>
    As with most approaches, we recommend you'll get more useful results if you use a mixture of the following techniques.
    While you don't need to use them all, you shouldn't confine yourself to using a single technique either.
</p>
<p>
    <b>Sub-topics:</b>
</p>
<ul>
    <li>
        <a href="#ManualTestScripts">Manual Test Scripts</a>
    </li>
    <li>
        <a href="#ProgramTestScripts">Programmed Test Scripts</a>
    </li>
    <li>
        <a href="#RecordTestScripts">Recorded or captured Test Scripts</a>
    </li>
    <li>
        <a href="#GenerateTests">Generated Tests</a>
    </li>
</ul>
<h4>
    <a id="ManualTestScripts" name="ManualTestScripts">Manual Test Scripts</a> <a href="#SelectImplementTechnique"><img     height="20" alt="To Select Implement Technique" src="./../../rup/resources/top.gif" width="26" border="0" /></a>
</h4>
<p>
    Many tests are best conducted manually, and you should avoid the trap of attempting to inappropriately automate tests.
    Usability tests are an area where manual testing is in many cases a better solution than an automated one. Also tests
    that require validation of the accuracy and quality of the physical outputs from a software system generally require
    manual validation. As a general heuristic, it's a good idea to begin the first tests of a particular Target Test Item
    with a manual implementation; this approach allows the tester to learn about the target item, adapt to unexpected
    behavior from it, and apply human judgment to determine the next appropriate action to be taken.
</p>
<p>
    Sometimes manually conducted tests will be subsequently automated and reused as part of a regression testing strategy.
    Note however that it isn't necessary or desirable-or even possible-to automate every test that you could otherwise
    conduct manually. Automation brings certain advantages in speed and accuracy of test execution, visibility and
    collation of detailed test results and in efficiency of creating and maintaining complex tests, but like all useful
    tools, it isn't the solution to all your needs.
</p>
<p>
    Automation comes with certain disadvantages: these basically amount to an absence of human judgment and reasoning
    during test execution. The automation solutions currently available simply don't have the cognitive abilities that a
    human does-and it's arguably unlikely that they ever will. During implementation of a manual test, human reasoning can
    be applied to the observed responses of the system to stimulus. Current automated test techniques and their supporting
    tools typically have limited ability to notice the implications of certain system behaviors, and have minimal ability
    to infer possible problems through deductive reasoning.
</p>
<h4>
    <a id="ProgramTestScripts" name="ProgramTestScripts">Programmed Test Scripts</a> <a href="#SelectImplementTechnique"><img height="20" alt="To Select Implement Technique"     src="./../../rup/resources/top.gif" width="26" border="0" /></a>
</h4>
<p>
    Arguably the method of choice practiced by most testers who use test automation. In it's purest form, this practice is
    performed in the same manner and using the same general principles as software programming. As such, most methods and
    tools used for software programming are generally applicable and useful to test automation programming.
</p>
<p>
    Using either a standard software development environment (such as Microsoft Visual Studio or IBM Visual Age) or a
    specialized test automation development environment (such as the IDE provided with Rational Robot), the tester is free
    to harness the features and power of the development environment to best effect.
</p>
<p>
    The negative aspects of programming automated tests are related to the negative aspects of programming itself as a
    general technique. For programming to be effective, some consideration should be given to appropriate design: without
    this the implementation will likely fail. If the developed software will likely be modified by different people over
    time-the usual situation-then some consideration must be given to adopting a common style and form to be used in
    program development, and ensuring it's correct use. Arguably the two most important concerns relate to the misuse of
    this technique.
</p>
<p>
    First, there is a risk that a tester will become engrossed in the features of the programming environment, and spend
    too much time crafting elegant and sophisticated solutions to problems that could be achieved by simpler means. The
    result is that the tester wastes precious time on what are essentially programming tasks to the detriment of time that
    could be spent actually testing and evaluating the Target Test Items. It requires both discipline and experience to
    avoid this pitfall.
</p>
<p>
    Secondly, there is the risk that the program code used to implement the test will itself have bugs introduced through
    human error or omission. Some of these bugs will be easy to debug and correct in the natural course of implementing the
    automated test: others won't. Just as errors can be elusive to detect in the Target Test Item, it can be equally
    difficult to detect errors in test automation software. Furthermore, errors may be introduced where algorithms used in
    the automated test implementation are based on the same faulty algorithms used by the software implementation itself.
    This results in errors going undetected, hidden by the false security of automated tests that apparently execute
    successfully. Mitigate this risk by using different algorithms in the automated tests wherever possible.
</p>
<h4>
    <a id="RecordTestScripts" name="RecordTestScripts">Recorded or captured Test Scripts</a> <a href="#SelectImplementTechnique"><img height="20" alt="To Select Implement Technique"     src="./../../rup/resources/top.gif" width="26" border="0" /></a>
</h4>
<p>
    There are a number of test automation tools that provide the ability to record or capture human interaction with a
    software application and produce a basic Test Script. There are a number of different tool solutions for this. Most
    tools produce a Test Script implemented in some form of a high-level, normally editable, programming language. The most
    common designs work in one of the following ways:
</p>
<ul>
    <li>
        Capturing the interaction with the client <a class="elementLink" href="./../../rup/guidances/termdefinitions/ui_929A0D03.html" guid="_yZZbg9nmEdmO6L4XMImrsA">UI</a>&nbsp;of an
        application based on intercepting the inputs sent from the client hardware peripheral input devices: mouse,
        keyboard and so forth to the client operating system. In some solutions, this is done by intercepting high-level
        messages exchanged between the operating system and the device driver that describe the interactions in a somewhat
        meaningful way; in other solutions this is done by capturing low-level messages, often based at the level of
        time-based movements in mouse coordinates or key-up and key-down events.
    </li>
    <li>
        Intercepting the messages sent and received across the network between the client application and one or more
        server applications. The successful interpretation of those messages relies typically on the use of standard,
        recognized messaging protocols, such as <a class="elementLink" href="./../../rup/guidances/termdefinitions/http_17BB6CED.html" guid="_yKCw5tnmEdmO6L4XMImrsA">HTTP</a>, <a class="elementLink" href="./../../rup/guidances/termdefinitions/sql_E258F221.html" guid="_yV9tCdnmEdmO6L4XMImrsA">SQL</a>&nbsp;and so forth. Some tools also allow the capture of "base"
        communications protocols such as <a class="elementLink" href="./../../rup/guidances/termdefinitions/tcp_ip_CE2F490E.html" guid="_yXmrw9nmEdmO6L4XMImrsA">TCP/IP</a>,
        however it can be more complex to work with Test Scripts of this nature.
    </li>
</ul>
<p>
    While these techniques are generally useful to include as part of your approach to automated testing, some
    practitioners feel these techniques have limitations. One of the main concerns is that some tools simply capture
    application interaction and do nothing else. Without the additional inclusion of observation points that capture and
    compare system state during subsequent script execution, the basic Test Script cannot be considered to be a
    fully-formed test. Where this is the case, the initial recording will need to be subsequently augmented with additional
    custom program code to implement observation points within the Test Script.
</p>
<p>
    Various authors have published books and essays on this and other concerns related to using test procedure record or
    capture as a test automation technique. To gain a more in-depth understanding of these issues, we recommend reviewing
    the work available on the Internet by the following authors: <a href="http://www.satisfice.com/" target="_blank">James
    Bach</a>, <a href="http://www.kaner.com/articles.html" target="_blank">Cem Kaner</a>, <a href="http://www.testing.com/writings.html" target="_blank">Brian Marick</a> and <a href="http://www.io.com/~wazmo/papers/" target="_blank">Bret Pettichord</a>, and the relevant content in the book
    <i>Lessons Learned in Software Testing</i> <a class="elementLinkWithUserText" href="./../../rup/customcategories/references_56F06DFD.html#KAN01" guid="7.755968586980351E-308">[KAN01]</a>
</p>
<h4>
    <a id="GenerateTests" name="GenerateTests">Generated Tests</a> <a href="#SelectImplementTechnique"><img height="20"     alt="To Select Implement Technique" src="./../../rup/resources/top.gif" width="26" border="0" /></a>
</h4>
<p>
    Some of the more sophisticated test automation software enables the actual generation of various aspects of the
    test-either the procedural aspects or the Test Data aspects of the Test Script-based on generation algorithms. This
    type of automation can play a useful part in your test effort, but shouldn't be considered a sufficient approach by
    itself. The Rational TestFactory tool and the Rational TestManager datapool generation feature are example
    implementations of this type of technology.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Set up test environment preconditions </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="Setup" name="Setup"></a> 
<div align="left">
    <table     style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"      cellspacing="0" bordercolordark="#808080" cellpadding="4" width="100%" bordercolorlight="#808080" border="1">
        <tbody>
            <tr>
                <td width="5%">
                    <b>Purpose:</b>&nbsp;
                </td>
                <td width="95%">
                    To ready the environment to the correct starting state.&nbsp;
                </td>
            </tr>
        </tbody>
    </table><br />
</div>
<p>
    Setup the test environment, including all hardware, software, tools, and data. Ensure all components are functioning
    properly. Typically this will involve some form of basic environment reset (e.g. resetting the <a class="elementLink" href="./../../rup/guidances/termdefinitions/windows_registry_2A6006F9.html" guid="_ycE8E9nmEdmO6L4XMImrsA">Windows 注册表（Windows registry）</a>&nbsp;and other configuration files), restoration of underlying databases to known state, and
    so forth in addition to tasks such as loading paper into printers. While some tasks can be performed automatically,
    some aspects typically require human attention.
</p>
<p>
    <b>Sub-topics:</b>
</p>
<ul>
    <li>
        <a href="#ManualCheck">(Optional) Manual walk-through of the test</a>
    </li>
    <li>
        <a href="#ConfirmTestOracles">Identify and confirm appropriateness of Test Oracles</a>
    </li>
    <li>
        <a href="#ResetEnvTools">Reset test environment and tools</a>
    </li>
</ul>
<h4>
    <a id="ManualCheck" name="ManualCheck">(Optional) Manual walk-through of the test</a> <a href="#Setup"><img height="20"     alt="To Setup" src="./../../rup/resources/top.gif" width="26" border="0" /></a>
</h4>
<p>
    Especially applicable to automated Test Scripts, it can be beneficial to initially walk-through the test manually to
    confirm expected prerequisites are present. During the walk-through, you should verify the integrity of the
    environment, the software and the test design. The walk-through is most relevant where you are using an interactive
    recording technique, and least relevant where you are programming the Test Script. The objective is to verify that all
    the elements required to implement the test successfully are present.
</p>
<p>
    Where the software is known to be sufficiently stable or mature, you way elect to skip this step where you deem the
    risk of problems occurring in the areas the manual walk-through addresses are relatively low.
</p>
<h4>
    <a id="ConfirmTestOracles" name="ConfirmTestOracles">Identify and confirm appropriateness of Test Oracles</a> <a href="#Setup"><img height="20" alt="To Setup" src="./../../rup/resources/top.gif" width="26" border="0" /></a>
</h4>
<p>
    Confirm that the <a class="elementLink" href="./../../rup/guidances/termdefinitions/test_oracle_CB9E18A9.html" guid="_yYNIs9nmEdmO6L4XMImrsA">测试预测（test oracle）</a>s&nbsp;you plan to use are appropriate. Where they have not already
    been identified, now is the time for you to do so.
</p>
<p>
    You should try to confirm through alternative means that the chosen Test Oracle(s) will provide accurate and reliable
    results. For example, if you plan to validate test results using a field displayed via the application's UI that
    indicates a database update has occurred, consider independently querying the back-end database to verify the state of
    the corresponding records in the database. Alternatively, you might ignore the results presented in an update
    confirmation dialog, and instead confirm the update by querying for the record through an alternative front-end
    function or operation.
</p>
<h4>
    <a id="ResetEnvTools" name="ResetEnvTools">Reset test environment and tools</a> <a href="#Setup"><img height="20"     alt="To Setup" src="./../../rup/resources/top.gif" width="26" border="0" /></a>
</h4>
<p>
    Next you should restore the environment-including the supporting tools-back to it's original state. As mentioned in
    previous steps, this will typically involve some form of basic operating environment reset, restoration of underlying
    databases to a known state, and so forth in addition to tasks such as loading paper into printers. While some reset
    tasks can be performed automatically, some aspects typically require human attention.
</p>
<p>
    Set the implementation options of the test-support tools, which will vary depending on the sophistication of the tool.
    Where possible, you should consider storing the option settings for each tool so that they can be reloaded easily based
    on one or more predetermined profiles. In the case of manual testing, it will include tasks such as partitioning a new
    entry in a support system for logging the test results, or signing into an issue and change request logging system.
</p>
<p>
    In the case of automated test implementation tools, there may be many different settings to be considered. Failing to
    set these options appropriately may reduce the usefulness and value of the resulting test assets.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Implement the test </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="ImplementTest" name="ImplementTest"></a> 
<div align="left">
    <table     style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"      cellspacing="0" bordercolordark="#808080" cellpadding="4" width="100%" bordercolorlight="#808080" border="1">
        <tbody>
            <tr>
                <td width="5%">
                    <b>Purpose:</b>&nbsp;
                </td>
                <td width="95%">
                    To implement one or more reusable test implementation assets.&nbsp;
                </td>
            </tr>
        </tbody>
    </table><br />
</div>
<p>
    Using the Test-Ideas List, or one or more selected Test Case artifacts, begin to implement the test. Start by giving
    the test a uniquely identifiable name (if it does not already have one) and prepare the IDE, capture tool, spreadsheet
    or document to begin recording the specific steps of the test. Work through the following subsections as many times as
    are required to implement the test.
</p>
<p>
    Note that for some specific tests or types of tests, there may be little value in documenting the explicit steps
    required to conduct the test. In certain styles of <a class="elementLink" href="./../../rup/guidances/termdefinitions/exploratory_testing_B3C6EB1B.html" guid="_yItULNnmEdmO6L4XMImrsA">探究式测试（exploratory testing）</a>&nbsp;repetition of the test is not an expected
    deliverable. For very simple tests, a brief description of the purpose of the tests will be sufficient in many cases to
    allow it to be reproduced.
</p>
<p>
    <b>Sub-topics:</b>
</p>
<ul>
    <li>
        <a href="#NavigationActions">Implement navigation actions</a>
    </li>
    <li>
        <a href="#ObservationPoint">Implement observation points</a>
    </li>
    <li>
        <a href="#ControlPoint">Implement control points</a>
    </li>
    <li>
        <a href="#ResolveImplementErrors">Resolve implementation errors</a>
    </li>
</ul>
<h4>
    <a id="NavigationActions" name="NavigationActions">Implement navigation actions</a> <a href="#ImplementTest"><img     height="20" alt="To top of page" src="./../../rup/resources/top.gif" width="26" border="0" /></a>
</h4>
<p>
    Program, record or generate the required navigation actions. Start by selecting your appropriate navigation method of
    choice. For most classes of system these days, a "Mouse" or other pointing device is the preferred and primary medium
    for navigation. For example, the pointing and scribing device used with a Personal Digital Assistants (PDA) is
    conceptually equivalent to a Mouse.
</p>
<p>
    The secondary navigation means is generally that of keyboard interaction. In most cases, navigation will be made up of
    a combination of mouse-driven and keyboard-driven actions.
</p>
<p>
    In some cases, you will need to consider voice-activated, light, visual and other forms of recognition. These can be
    more troublesome to automate tests against, and may require the addition of special test-interface extensions to the
    application to allow audio and visual elements to be loaded and processed from file rather than captured dynamically.
</p>
<p>
    In some situations, you may want to-or need to-perform the same test using multiple navigation methods. There are
    different approaches you can take to achieve this, for example: automate all the tests using one method and manually
    perform all or some subset of the tests using others; separate the navigation aspects of the tests from the Test Data
    that characterize the specific test, providing and building a logical navigation interface that allows either method to
    be selected to drive the test; simply mix and match navigation methods.
</p>
<h4>
    <a id="ObservationPoint" name="ObservationPoint">Implement observation points</a> <a href="#ImplementTest"><img     height="20" alt="To top of page" src="./../../rup/resources/top.gif" width="26" border="0" /></a>
</h4>
<p>
    At each point in the Test Script where an observation should be taken, use the appropriate Test Oracle to capture the
    desired information. In many cases, the information gained from the observation point will need to be recorded and
    retained to be referenced during subsequent control points.
</p>
<p>
    Where this is an automated test, decide how the observed information should be reported from the Test Script. In most
    cases it usually appropriate simply to record the observation in a central Test Log relative to it's delta-time from
    the start of the Test Script; in other cases specific observations might be output separately to a spreadsheet or data
    file for more sophisticated uses.
</p>
<h4>
    <a id="ControlPoint" name="ControlPoint">Implement control points</a> <a href="#ImplementTest"><img height="20"     alt="To top of page" src="./../../rup/resources/top.gif" width="26" border="0" /></a>
</h4>
<p>
    At each point in the Test Script where a control decision should be taken, obtain and assess the appropriate
    information to determine the correct branch for the flow of control to follow. The data retrieved form prior
    observation points are usually input to control points.
</p>
<p>
    Where a control point occurs, and a decision made about the next action in the flow-of-control, we recommend you record
    the input values to the control point, and the resulting flow that is selected in the Test Log.
</p>
<h4>
    <a id="ResolveImplementErrors" name="ResolveImplementErrors">Resolve errors in the test implementation</a> <a href="#ImplementTest"><img height="20" alt="To top of page" src="./../../rup/resources/top.gif" width="26"     border="0" /></a>
</h4>
<p>
    During test implementation, you'll likely introduce errors in the test implementation itself. Those errors may even be
    the result of things you've omitted from the test implementation or may be related to things you've failed to consider
    in the test environment. These errors will need to be resolved before the test can be considered completely
    implemented. Identify each error you encounter and work through addressing them.
</p>
<p>
    In the case of test automation that uses a programming language, this might include compilation errors due to
    undeclared variables and functions, or invalid use of those functions. Work your way through the error messages
    displayed by the compiler or any other sources of error messages until the Test Script is free of syntactical and other
    basic implementation errors.
</p>
<p>
    Note that during subsequent execution of the test, other errors in the test implementation might be found. Initially
    these may appear to be failures in the target test item - you need to be diligent when analyzing test failures that you
    confirm the failures are actually in the target test item, and not in some aspect of the test implementation.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Establish external data sets </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="EstablishExternalData" name="EstablishExternalData"></a>
<div align="left">
    <table border="1" width="100%" cellspacing="0" cellpadding="4" style="border: 1px solid rgb(128,128,128)"     bordercolorlight="#808080" bordercolordark="#808080">
        <tr>
            <td width="5%">
                <b>Purpose:</b>&nbsp;
            </td>
            <td width="95%">
                To create and maintain data, stored externally to the test script, that are used by the test during
                execution.&nbsp;
            </td>
        </tr>
    </table><br />
</div>
<p>
    In many cases it's more appropriate to maintain your Test Data external to the Test Script. This provides flexibility,
    simplicity and security in Test Script and Test Data maintenance. External data sets provide value to test in the
    following ways:
</p>
<ul>
    <li>
        Test Data is external to the Test Script eliminating hard-coded references in the Test Script
    </li>
    <li>
        External Test Data can be modified easily, usually with minimal Test Script impact
    </li>
    <li>
        Additional Test Cases can easily be supported by the Test Data with little or no Test Script modifications
    </li>
    <li>
        External Test Data can be shared with many Test Scripts
    </li>
    <li>
        Test Scripts can be developed to use external Test Data to control the conditional branching logic within the Test
        Script.
    </li>
</ul></td>
</tr>
</table>
</div>
<div class="stepHeading"> Verify the test implementation </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="VerifyTestImplementation" name="VerifyTestImplementation"></a> 
<div align="left">
    <table     style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"      cellspacing="0" bordercolordark="#808080" cellpadding="4" width="100%" bordercolorlight="#808080" border="1">
        <tbody>
            <tr>
                <td width="5%">
                    <b>Purpose:</b>&nbsp;
                </td>
                <td width="95%">
                    To verify the correct workings of the Test Script by executing the Test Script.&nbsp;
                </td>
            </tr>
        </tbody>
    </table><br />
</div>
<p>
    Especially in the case of test automation, you will probably need to spend some time stabilizing the workings of the
    test when it is being executed. When you have completed the basic implementation of the Test Script, it should be
    tested to ensure it implements the individual tests appropriately and that they execute properly.
</p>
<h4>
    <a id="Recover" name="Recover">Recover test environment to known state</a> <a href="#VerifyTestImplementation"><img     height="20" alt="To Verify Test Implementation" src="./../../rup/resources/top.gif" width="26" border="0" /></a>
</h4>
<p>
    Again, you should restore the environment back to it's original state, cleaning up after your test implementation work.
    As mentioned in previous steps, this will typically involve some form of basic operating environment reset, restoration
    of underlying databases to known state, and so forth in addition to tasks such as loading paper into printers. While
    some tasks can be performed automatically, some aspects typically require human attention.
</p>
<h4>
    <a id="SetupandPlayback" name="SetupandPlayback">Setup tools and initiate test execution</a> <a href="#VerifyTestImplementation"><img height="20" alt="To Verify Test Implementation"     src="./../../rup/resources/top.gif" width="26" border="0" /></a>
</h4>
<p>
    Especially in the case of test automation, the settings within the supporting tools should be changed The objective is
    to verify the correct workings of the Test Script by executing the Test Script.
</p>
<p>
    It's a good idea to perform this step using the same Build version of the software used to implement the Test Scripts.
    This eliminates the possibility of problems due to introduced errors in subsequent builds.
</p>
<h4>
    <a id="ResolveExecutionErrors" name="ResolveExecutionErrors">Resolve execution errors</a> <a href="#VerifyTestImplementation"><img height="20" alt="To Verify Test Implementation"     src="./../../rup/resources/top.gif" width="26" border="0" /></a>
</h4>
<p>
    It's pretty common that some of the things done and approaches used during implementation will need a degree of
    adjustment to enable the test to run unattended, especially in regard to executing the test under multiple Test
    Environment Configurations.
</p>
<p>
    In the case of test automation, be prepared to spend some time checking and the tests "function within tolerances" and
    adjusting them until they work reliably before you declare the test as implemented. While you might delay this step
    until later in the lifecycle (e.g. during Test Suite development), we recommend that you don't: otherwise you could end
    up with a significant backlog of failures that need to be addressed.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Restore test environment to known state </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="Restore" name="Restore"></a>
<div align="left">
    <table border="1" width="100%" cellspacing="0" cellpadding="4" style="border: 1px solid rgb(128,128,128)"     bordercolorlight="#808080" bordercolordark="#808080">
        <tr>
            <td width="5%">
                <b>Purpose:</b>&nbsp;
            </td>
            <td width="95%">
                To leave the environment either the way you found it, or in the required state to implement the next
                test.&nbsp;
            </td>
        </tr>
    </table><br />
</div>
<p>
    While this step might seem trivial, but it's an important good habit to form to work effectively with the other testers
    on the team-especially where the implementation environment is shared. It's also important to establish a routine that
    makes thinking of the system state second nature.
</p>
<p>
    While in a primarily manual testing effort, it's often simple to identify and fix environment restore problems,
    remember that test automation has much less ability to tolerate unanticipated problems with environment state.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Maintain traceability relationships </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="Traceability" name="Traceability"></a>
<div align="left">
    <table border="1" width="100%" cellspacing="0" cellpadding="4" style="border: 1px solid rgb(128,128,128)"     bordercolorlight="#808080" bordercolordark="#808080">
        <tr>
            <td width="5%">
                <b>Purpose:</b>&nbsp;
            </td>
            <td width="95%">
                To enable impact analysis and assessment reporting to be performed on the traced items.&nbsp;
            </td>
        </tr>
    </table><br />
</div>
<p>
    Using the Traceability requirements outlined in the Test Plan, update the traceability relationships as required.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Evaluate and verify your results </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="EvaluateResults" name="EvaluateResults"></a> 
<div align="left">
    <table     style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"      cellspacing="0" bordercolordark="#808080" cellpadding="4" width="100%" bordercolorlight="#808080" border="1">
        <tbody>
            <tr>
                <td width="5%">
                    <b>Purpose:</b>&nbsp;
                </td>
                <td width="95%">
                    To verify that the task has been completed appropriately and that the resulting work products are
                    acceptable.&nbsp;
                </td>
            </tr>
        </tbody>
    </table><br />
</div>
<p>
    Now that you have completed the work, it is a good practice to verify that the work was of sufficient value. You should
    evaluate whether your work is of appropriate quality, and that it is complete enough to be useful to those team members
    who will make subsequent use of it as input to their work. Where possible, use the checklists provided in NUP to verify
    that quality and completeness are "good enough".
</p>
<p>
    Have the people who will use your work as input in performing their downstream tasks take part in reviewing your
    interim work. Do this while you still have time available to take action to address their concerns. You should also
    evaluate your work against the key input work products to make sure you have represented or considered them
    sufficiently and accurately. It may be useful to have the author of the input work product review your work on this
    basis.
</p>
<p>
    Try to remember that that NUP is an iterative delivery process and that in many cases work products evolve over time.
    As such, it is not usually necessary-and is in many cases counterproductive-to fully-form a work product that will only
    be partially used or will not be used at all in immediately subsequent downstream work. This is because there is a high
    probability that the situation surrounding the work product will change-and the assumptions made when the work product
    was created proven incorrect-before the work product is used, resulting in rework and therefore wasted effort.
</p>
<p>
    Also avoid the trap of spending too many cycles on presentation to the detriment of the value of the content itself. In
    project environments where presentation has importance and economic value as a project deliverable, you might want to
    consider using an administrative or junior resource to perform work on a work product to improve it's presentation.
</p><br />
<br /></td>
</tr>
</table>
</div>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Properties</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row" id="property_Multiple Occurrences" abbr="Multiple Occurrences">Multiple Occurrences</th><td class="sectionTableCell" align="left" headers="property_Multiple Occurrences"><img width="20" height="15" alt="" title="" src="./../../images/indent.gif"></td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row" id="property_Event Driven" abbr="Event Driven">Event Driven</th><td class="sectionTableCell" align="left" headers="property_Event Driven"><img width="20" height="15" alt="" title="" src="./../../images/indent.gif"></td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row" id="property_Ongoing" abbr="Ongoing">Ongoing</th><td class="sectionTableCell" align="left" headers="property_Ongoing"><img width="20" height="15" alt="" title="" src="./../../images/indent.gif"></td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row" id="property_Optional" abbr="Optional">Optional</th><td class="sectionTableCell" align="left" headers="property_Optional"><img width="20" height="15" alt="" title="" src="./../../images/indent.gif"></td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row" id="property_Planned" abbr="Planned">Planned</th><td class="sectionTableCell" align="left" headers="property_Planned"><img width="20" height="15" alt="" title="" src="./../../images/indent.gif"></td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row" id="property_Repeatable" abbr="Repeatable">Repeatable</th><td class="sectionTableCell" align="left" headers="property_Repeatable"><img width="20" height="15" alt="" title="" src="./../../images/indent.gif"></td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright">Copyright &copy; 2008 版权所有 东软集团股份有限公司&nbsp; 联系邮箱:<a href="mailto:tcoe@neusoft.com">tcoe@neusoft.com</a></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script language="JavaScript" type="text/javascript">
					contentPage.onload();
					contentPage.processPage.fixDescriptorLinks();
				</script>
</html>
